The expansion of information service and data processing industries has resulted in a need for computer systems to manage and store large amounts of data. Data storage system developers have responded to these types of data storage requirements by integrating large capacity data storage systems into networks called storage area networks (SANs). A SAN is a collection of networked data storage devices and storage processors that operate to serve data stored in the data storage devices to end-user or host devices. When exchanging data read/write requests with the SAN, the host device can utilize various types of communications protocols based upon the configuration of the SAN. For example, certain SANs (e.g., Internet Protocol (IP)-SANs) are configured to utilize the Internet Small Computer System Interface (iSCSI) protocol for exchanging SCSI commands and data over an Internet Protocol (IP) network. The iSCSI protocol allows the host device to access the storage devices over the IP network using block-based input/output (I/O) commands.
During operation, the storage processors of the IP-based SANs typically receive both iSCSI (e.g., block-based) traffic as well as TCP/IP (e.g., non-iSCSI) network traffic from host devices. Conventionally, within the IP-based SAN, iSCSI traffic constitutes a relatively high-volume of traffic while non-iSCSI (e.g., TCP/IP) traffic constitutes a relatively low volume of traffic supporting standard network services such as ping, trace route, iSNS, etc. In order to accelerate network input/output (I/O) within the IP-based SAN, the storage processors can be configured to process both the iSCSI traffic and the TCP/IP network traffic running the same proprietary driver. For example, conventional storage processors include TCP/IP offload engine (TOE) devices, such as iSCSI controller model ISP4010 distributed by QLogic Corporation, Aliso Viejo, Calif., to accelerate both iSCSI and the TCP/IP network traffic through the storage processors running the same device driver.
In certain IP-based SANs, the TOE devices are configured, in firmware, to differentiate between iSCSI and non-iSCSI traffic and direct the traffic to the appropriate driver for processing. For example, FIG. 1 illustrates a conventional IP-based SAN 10 that includes a host device 12 in communication with a storage processor 15 via network 14. The storage processor 15 includes a TOE device 18 coupled to a controller 24 by a PCI bus 26. Once connected to the PCI bus 26, during a boot-up procedure, the TOE device 18 presents two functions to the controller 24 over the PCI bus 26: an iSCSI communications function and a non-ISCI communications function. As such, the TOE device 18 notifies the controller 24 that it is capable of handling both iSCSI and non-iSCSI traffic. The controller 24, such as a microprocessor, runs an operating system that includes a proprietary iSCSI driver 20 and a standard network driver 22 (e.g., the Microsoft NDIS network driver), capable of processing iSCSI and non-iSCSI traffic, respectively, as received from the TOE device 18.
During operation, when the TOE device 18 receives a communications packet from the host device 12. In order to differentiate between iSCSI and non-iSCSI traffic, firmware logic 25 of the TOE device 18 examines a destination port number associated with the packet to determine the appropriate driver 20, 22 to be used in processing the communications packet. For example, in the case where the destination port number is equal to a preset value, such as a port value of 3260, the firmware logic 25 detects that the communications packet is part of an iSCSI communication from the host device 12. As a result, the firmware logic 25 passes the packet to an iSCSI processing function 30 associated with the TOE device 18 which, in turn, passes the iSCSI packet to the iSCSI driver 20, via the bus 26, for processing. In the case where the destination port number is not equal to a preset value, such as a port value of 3260, the firmware logic 25 detects that the communications packet is part of a non-iSCSI communication from the host device 12. As a result, the firmware logic 25 passes the packet, via the bus 26, to the network driver 22, for processing by standard operating system network services.